iT邦幫忙

2024 iThome 鐵人賽

DAY 0
0
自我挑戰組

非開發團隊的敏捷實踐與觀察系列 第 1

Day 1 就 NG 的鐵人賽,驗證了「非同步協作」要「過度溝通」

  • 分享至 

  • xImage
  •  

https://ithelp.ithome.com.tw/upload/images/20240916/20169386oVGqwiY5Gk.png

今天打開發文頁面,發現我的鐵人賽還沒開始就結束了呢(嗯?)

https://ithelp.ithome.com.tw/upload/images/20240916/20169386nmWpChy5pW.jpg

今年會決定參賽,起因於幾天前的 Hello World 活動,我們家的說書人湯湯擔任其中一場 panel 的主持人,在前一晚的彩排時,和講者們聊到了最近鈦坦文創推出的「鑽石提袋」,設計概念源自於敏捷大前輩 Esther Derby,去年獲鈦坦科技邀請到 Agile Summit keynote 的講題 “Leaders at All Levels”;另外,講者之一 Hahow 產品總監 Samuel 提到讀了《打造敏捷企業》這本書深有所感,我因此延伸分享了去年鈦坦科技針對此書辦了導讀會的花絮;以及聊到我們近年推動的「全齡敏捷」,其中針對中、小學生族群打造的「敏捷虎鯨島」遊戲,就是和講者之一 BoniO 產品總監 Alan 公司的遊戲平台 PaGamO 合作。

總之聊到一個,我就忍不住毛遂自薦分享一篇文章,感謝台灣敏捷協會理事 Jensen 用行動支持,每篇 medium 文章都扎扎實實按了 50 個 clap,總計按了 150 下(Jensen 表示:妳也一下傳來太多篇⋯⋯)

同事 Eviler 在旁邊看著我的老王賣瓜,一時興起推坑我報名鐵人賽,鼓勵在 PR team 本來就負責寫長文的我,既然已存素材這麼多,何不同步整理一下發在鐵人賽呢?原本以為哈哈哈哈哈就可以被我打哈哈過去,但學習型組織不是在開玩笑的,熱愛分享、鼓勵交流的氛圍之濃厚,延續到隔天 Hello World 的攤位現場。

鈦坦科技持續用實際行動支持並贊助技術社群,今年我們也是 Hello World 的贊助商,我們會把握實體攤位的機會和會眾實體互動交流,因此現場去了不少鈦坦人,其中也包含了推坑王 Eviler。劈頭就問我鐵人賽報名了沒,接著還把我拉到天瓏書局的攤位前,一睹歷年鐵人賽系列書。

是說本來就有點想要挑戰看看的我,在推波助瀾下決定來挑戰一下自己,抱著筆電坐在攤位後方的地板上就果斷地報了名,還順手拉了另個同事 Leo 一起參賽,想說有人可以互相提醒⋯⋯

BUT!就是這個 BUT!

9 月 16 日,星期一,一早。我帶著琢磨了一整個週末的想法準備來發文,還不忘先到 Slack 上跟被我拖下水一起參賽的好夥伴 Leo 喊聲,提醒他別忘了上傳鐵人賽的第一篇唷 :)

https://ithelp.ithome.com.tw/upload/images/20240916/20169386ExG8vDa7sk.png

結果就是大家現在看到的這樣了(苦笑)。


作為品牌公關(PR,Public Relationship),即便我的日常工作與軟體開發可以說是毫不相干,但仍能落實敏捷到工作流之中,其中「溝通」的重要性可見一斑,就拿參加鐵人賽第一天就 NG 這個事件來做舉例好了。

敏捷溝通重要的條件之一,就是「資訊透明化程度」(Transparency)。

Leo 說,在 9/15(日) 晚上壓尾線發布文章時,其實他心中就閃過是不是要發個訊息提醒我的念頭,但當時想說我應該不可能忘記吧,畢竟鐵人賽還是我揪他報名的,我應該會記得吧。事實上,我的確也不是忘記了,而是根本就打從心底覺得開賽日是 9/16(一) 截止。

有了前車之鑑在先,讓我們來討論看看怎麼做才不會重蹈覆徹。

首先,能不用人腦記憶就不要仰賴有限的記憶力,盡可能用工具記下來並確保能對齊協作。舉例來說,開賽日我憑印象認定是 9/16,實際上報名當下曾經和 Leo 一起確認過是 9/15,但我內心不知哪裡植入的資訊,認定了就是下週一開始,於是演變成過了 deadline 也不自覺的狀態。

對應到工作上來說,發 Google Calendar、在 Confluence 上建立 KM、Notion 上開 Task 追蹤彼此進度,都是我們減少掉球的方式,尤其在混合辦公的情境下,經常出現非同步協作的模式,這也有助於我們確保資訊對齊。

再來,你以為你以為的就是你以為的嗎?非同步協作下,過度溝通才是適度溝通。除了非同步協作可能帶來的資訊落差,跨團隊合作也常常讓我們「不在同一頁」(not on the same page),因此我們經常會強調「重要的事重複說」,而且嘗試用不同的方式說。

舉例來說,在開會前我們會先將 outline 列出,並在開會時同步紀錄討論的重點,結束前重述一遍,可以的話列成待辦事項並給予明確的時限;當會議結束之後,將帶有時限的待辦事項貼到聊天室讓彼此再看過一次,讓相關人等可以透過不同階段的討論,一再地確認和對齊。

經實驗證明,過度溝通永遠不嫌多,因為透過不同方式的確認,能夠一再針對認知差異的部分取得共識或進一步討論,總比做完了才發現做錯了更好!相信我,不厭其煩能為你省下很多麻煩!

不過,關於「資訊透明化」(Transparency)有一點很重要的原則要說明:

透明化的目的是爲了讓大家工作更順暢,所以過度透明會造成資訊爆炸,比如過度會議,反而使得工作的效益降低,所以透明化拿捏要以工作為核心出發,而不是所有事情或資訊都要透明化。

資訊透明並非無限上綱,先確認這項資訊透明後是否利大於弊,可以降低過度溝通所帶來的焦慮,因為不是過度溝通出了問題,而是錯誤的溝通才大有問題。


雖然第一天在很 NG 的狀況下開始,但第一篇就從日常俯拾皆是的狀況進行分享,對我也是一個平易近人的開始,期望能夠順利完成接下來 29 篇的挑戰(笑)


系列文
非開發團隊的敏捷實踐與觀察1
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

1 則留言

0
Leo Chiang
iT邦新手 4 級 ‧ 2024-09-17 23:24:11

每個經驗都是成長的養分

我要留言

立即登入留言